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SECTION  I 


INTRODUCTION 


This  paper  discusses  recent  developments  In  the  field  of  computer 
security  technology  and  how  these  developments  can  be  Incorporated 
into  existing  ADP  directives.  It  is  Important  to  note  that,  while  the 
complete  security  of  a system  Is  dependent  on  the  factors  of  many 
areas  (physical,  emanations,  communications),  this  paper  treats  only 
the  area  of  hardware /software  controls  In  an  ADP  system.  Toward  this 
end,  the  paper  consists  of  three  main  sections:  Security  Policy  in 
ADP  Systems,  Additions  and  Modifications  to  Existing  Directives,  and 
Conclusions  and  Recommendations. 

In  the  Security  Policy  In  ADP  Systems  section,  topics  discussed 
include  DoD  security  policy,  security  practice  In  current  ADP  systems, 
the  multilevel  security  problem,  and  examples  of  multilevel  secure 
systems.  Based  on  the  discussion,  areas  are  Identified  where  the 
directives  must  be  changed  to  reflect  the  advances  In  computer 
security  technology. 

The  Additions  and  Modifications  to  Existing  Directives  section 
Identifies  the  additions  necessary  for  the  following:  DoD  Directive 
52UU.28,  DoD  Manual  5200. 2dM,  and  Air  Force  Regulation  300-8. 

Lastly,  the  Conclusions  and  Recommendations  section  suggests  the 
action  to  be  taken  In  light  of  the  discussion  presented. 

The  goals  of  this  paper  are  to  show  how  computer  security 
technology  has  advanced,  and  to  show  how  the  appropriate  directives 
and  regulations  could  be  changed  to  reflect  these  advances.  It  Is 
Interesting  to  note  that  DoD  5200.28  states  the  necessity  to  upgrade 
the  security  measures  put  forth  in  the  regulations  when  "experience 
and  new  techniques  are  acquired  under  actual  operating  conditions  or 
as  a result  of  follow-on  testing  and  evaluation  procedures." 
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SECTION  II 


SECURITY  POLICY  IW  ADP  SYSTEMS 


This  section  discusses  DoD  security  policy  and  Its  Implementation 
In  ADP  systems.  The  policy  is  reviewed  for  both  the  paper  environment 
and  ADP  systems.  Current  ADP  security  practices  and  the  development 
of  multilevel  secure  systems  are  discussed.  Examples  of  systems 
operating  In  a multilevel  secure  mode  are  presented,  as  well  as  the 
application  of  computer  security  technology  to  the  development  of 
future  DoO  systems.  A summary  of  the  major  features  of  computer 
security  technology,  and  their  Impact  on  the  existing  DoD  directives. 
Is  also  Included. 


SECURITY  POLICY 

Security  policy  In  an  ADP  system  Is  drawn  from  the  policy 
applicable  to  the  paper  environment  (I),  but  with  certain  additions  to 
reflect  the  added  dimension  of  computer  processing  of  classified 
Information. 

Security  policy  states  that  official  material  shall  be  afforded 
the  level  of  protection  against  unauthorized  disclosure  commensurate 
with  the  level  of  classification  assigned.  Classified  material  may  be 
used,  held,  or  stored  only  where  there  are  facilities  or  conditions 
adequate  to  prevent  unauthorized  persons  from  gaining  access  to  It. 

Any  security  requirements  necessary  to  protect  classified  Information 
must  not  be  so  restrictive  as  to  prevent  the  accoiiq>llshraent  of 
essential  functions. 

An  ADP  security  policy  defines  the  access  attributes  of  subjects 
and  objects.  (The  notion  of  subjects  and  objects,  when  dealing  with 
ADP  system  security,  was  first  presented  in  (2).)  A subject  Is 
defined  as  an  active  system  element  that  Is  capable  of  requesting 
access  to  Information;  In  the  paper  environment,  a person  can  be 
considered  as  a subject,  while  In  the  ADP  environment,  a program  or 
process  running  on  behalf  of  a user  would  be  considered  as  a subject. 
An  object  Is  defined  as  a repository  of  Information.  In  the  paper 
environment,  objects  would  be  classified  documents  or  Information;  In 
the  ADP  environment,  objects  would  be  data  or  flies. 

Two  security  properties  exist  that  must  be  satisfied  In  both  the 
paper  and  ADP  environments.  The  first  property  requires  that  a 
subject  shall  not  be  permitted  to  read  an  object  of  a hlgih*^ 
classification  than  It  Is  cleared  to  access.  In  the  paper 
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environment,  a person  Is  not  permitted  to  read  classified  Information 
unless  he  Is  cleared  to  at  least  the  security  classification  of  the 
Information.  In  the  ADP  environment,  a subject  (l.e.,  a process)  at 
O'le  classification  cannot  access  data  or  files  at  a higher 
classification. 

The  second  property  forbids  a subject  from  taking  Information  of 
one  classification  and  rewriting  It  at  a lower  classification.  This 
property  points  out  the  difference  between  the  paper  and  ADP 
environments.  In  the  paper  environment,  a person  Is  acting  on  his  own 
behalf  when  accessing  classified  Information.  Each  person  Is 
considered  a Crusted  subject,  and,  as  such,  the  person  Is  Crusted  not 
to  disclose  any  classified  Information  to  persons  who  are  not  suitably 
cleared.  On  Che  other  hand.  In  the  ADP  environment,  a person  Is  not 
directly  accessing  any  classified  information;  that  Is,  an  executing 
program  or  process,  on  behalf  of  Che  user,  accesses  classified  data 
and  files  as  required.  For  this  situation  to  be  analogous  Co  the 
paper  environment,  the  user  program  must  be  trusted  not  to  downgrade 
any  classified  Information  Co  which  it  has  access.  For  a program  to 
be  designated  as  trusted.  It  must  be  verified  to  act  In  a specified 
manner;  In  actual  practice,  the  necessity  to  Insure  the  correctness  of 
a Crusted  program  results  In  all  but  a few  programs  being  designated 
as  non-crusted.  Consequently,  In  the  ADP  environment,  special 
precautions  must  be  Implemented  to  Insure  that  a non-trusted  subject 
cannot  purposely  or  Inadvertently  transfer  Information  of  one 
classification  to  a lower  classification. 

In  addition  to  a security  clearance,  a person  must  have  a need 
for  access  to  Che  particular  classified  Information  or  material  In 
connection  with  the  performance  of  his  official  duties  or  contractual 
obligations.  In  Che  paper  environment,  this  restriction  Is 
Implemented  through  the  use  of  "need-to-know"  controls.  In  an  ADP 
system,  this  restriction  Is  referred  to  as  discretionary  control. 
Discretionary  controls  Implement  a protection  policy  that  may  be 
dynamically  defined  by  tne  user,  and  they  correspond  directly  with  the 
manual  need-to-know  controls.  Non-dlscretlonary  controls  Implement  a 
protection  policy  that,  once  defined  for  an  object.  Is  unchangeable 
and  must  be  satisfied  at  all  times.  The  policy  addressing  protection 
of  national  security  Information  based  on  a person's  clearance  and  the 
Information's  classification  Is  a non-dlscretlonary  security  policy. 

In  ADP  systems,  the  problem  Is  that  of  providing  the  necessary 
controls  to  satisfy  the  security  policy,  while,  at  the  same  time, 
allowing  the  most  efficient  use  of  computer  resources  by  persons 
desiring  to  process  data  of  various  security  classifications. 
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CURREUT  ADP  SECURITY  PRACTICE 


Most  current  ADP  systems  use  special  procedures  for  processing 
classified  Information.  These  procedures  normally  either  permit  only 
one  security  level  of  Information  to  be  processed  at  a time,  or 
require  that  all  users  be  cleared  to  the  highest  level  In  the  system. 
Such  an  ADP  system  Is  housed  In  a facility  cleared  for  the  highest 
security  level  processed,  and  access  Is  restricted  to  appropriately 
cleared  Individuals.  If  remote  users  must  be  supported  by  the  ADP 
system,  the  personnel  at  the  remote  sites  must  also  be  cleared  and 
their  terminals  housed  In  secure  areas.  The  remote  terminals  and 
central  facility  must  be  linked  by  encrypted  or  protected 
communications  circuits. 

The  two  alternatives  for  processing  several  levels  of  classified 
Information  In  ADP  systems  where  adequate  multilevel  security 
protection  Is  unavailable  are  system-high  operation  and  dedicated 
operation.  These  terms  are  defined  below: 

o System-High  Operation  - All  security  levels  may  be  processed 
together,  provided  that  all  users  and  terminal  areas  are 
cleared  for  the  highest  level  of  Information  that  could  be 
processed  on  the  system.  All  output  from  a system-high 
computer  must  be  considered  at  the  system-high  level  until  It 
has  been  manually  reviewed. 

o Dedicated  Operation  - Each  level  may  be  processed  at  a 
separate  time.  In  which  case  the  entire  system  environment 
must  be  changed  or  sanitized  at  each  change  of  security  level. 

System-high  operation  requires  an  unnecessary  profusion  of 
personnel  clearances,  secure  terminal  areas,  and  secure 
communications.  The  dedicated  operation  requires  that  a procedure 
called  "color-changing"  be  carried  out  when  switching  between 
different  security  levels.  Dedicated  operation  allows  uncleared 
terminals  to  be  connected  provided  they  are  detached  before  classified 
processing  begins;  however,  each  change  of  environment  wastes  a 
significant  amount  of  system  time  while  sanitization  Is  being 
completed.  In  either  case,  system-high  or  dedicated  operation,  the 
processing  of  multiple  levels  of  classified  Information  Involves 
Increased  cost.  Inconvenience,  and  system  Inefficiency. 


COMPUTER  SECURITY  REQUIREMENTS 

It  Is  clear  that  major  problems  have  been  encountered  with  the 
use  of  current  ADP  practices  for  processing  multiple  classifications 
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* of  Information,  especially  In  the  areas  of  system  costs  and 

operational  capabilities. 

Cost  Impacts 

The  cost  Impacts  of  computer  security  have  been  reflected  In 
expenditures  for  Increased  protection,  additional  equipment,  and 
Inefficient  system  utilization.  Additional  personnel  clearances, 
vault  areas,  and  secure  communications  may  be  required  to  allow  users 
to  do  unclassified  processing  on  computers  that  handle  classified 
data.  For  example,  at  Lhe  Air  Force  Data  Services  Center  (AFDSC),  the 
cost  of  securing  each  remote  site  was  estimated  at  $50,000. 

Computer  Installations  operating  In  a system-high  mode  that  must 
I provide  responsive  support  to  user  communities  of  various  clearance 

levels  have  had  to  purchase  additional  equipment.  At  AFDSC,  a 
timesharing  system  was  acquired  to  provide  unclassified  computing 
services  to  users  In  open  office  areas,  supplementing  the  classified 
processing  systems  supporting  users  In  secure  terminal  areas.  In 
other  cases,  additional  computers  have  been  purchased  to  provide 
support  to  both  classified  and  unclassified  users. 

Inefficient  system  utilization  results  when  a system  must  be 
switched  from  processing  at  one  classified  level  to  another  level. 

This  switching,  known  as  "color  changing",  requires  that  all 
processing  of  one  security  level  be  completed,  system  memories 
cleared,  and  a new  version  of  the  system  be  brought  up  before 
processing  at  another  level  can  begin.  The  time  required  to  perform 
the  color  change  and  restart  the  system  ranges  from  twenty  to 
forty-five  minutes.  The  color  change's  effect  may  be  propagated  over 
one  to  two  hours  of  processing  time  by  refusing  long  jobs  and  saving 
files  on  backup  tapes.  Color  changes  are  used  In  cases  where 
responsiveness  and  workload  do  not  require  dedication  of  a computer  to 
a given  level  for  an  Indefinite  period.  Such  changes  can  use  ten  to 
twenty  percent  of  a system's  processing  capacity. 

Operational  Impacts 

Operational  requirements  for  secure  computers  have  been  met,  when 
possible,  by  the  two  methods  previously  discussed:  using  a separate 
computer  for  each  level,  or  clearing  all  users  to  the  highest  level 
being  processed.  These  methods,  however,  do  not  satisfy  the 
classified  processing  needs  of  some  cases,  such  as  when  only  a small 
portion  of  the  data  Is  classified  or  when  the  rapid  transfer  of 
Information  Is  required  between  operational  forces. 

In  the  first  case,  where  a small  portion  of  the  data  Is 
classified,  manual  processing  must  be  done  on  such  data  so  that  It  Is 
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not  necessary  to  operate  a system  at  the  higher  classification. 
Clearly,  the  operational  impact  of  any  delays  resulting  from  the 
manual  processing  could  be  considerable,  especially  when  rapid 
response  to  developing  situation  is  critical. 

The  second  case,  the  transfer  of  information  between  operational 
forces,  is  exemplified  by  the  difficulty  in  integrating  intelligence 
and  operational  data.  Such  integration  is  required  for  responsive 
force  management,  but  it  must  be  done  so  as  not  to  Jeopardize 
intelligence  sources.  Since  it  is  often  impossible  to  clear  all 
system  users  for  the  intelligence  data,  manual  intervention  is  used: 
a cleared  intelligence  officer  hands  a subset  of  the  data  to  the 
operations  clement.  However,  as  automated,  timely  integration  of  such 
data  becomes  necessary,  manual  handling  becomes  unacceptable,  and  a 
direct  technological  solution  to  the  problem  of  handling  multiple 
classifications  of  information  in  an  ADP  system  becomes  necessary. 


liULTILEVEL  SECURITY  IN  ADP  SYSTEMS 

The  economic  and  operational  considerations  previously  discussed 
point  to  the  need  for  developing  the  ability  to  process  an  arbitrary 
nix  of  classified  and  unclassified  information  simultaneously  with  a 
single  computer,  serving  cleared  and  uncleared  users,  and  relying  on 
the  computer's  and  operating  system's  internal  controls  to  enforce 
security  and  need-to-know  requirements.  Such  a computer  would  be 
operating  in  a true  multilevel  security  mode.  Two  types  of  multilevel 
secure  operation  are:  controlled — this  operation  would  support  users 
of  different  classifications,  although  all  users  would  be  cleared  to 
some  minimum  level  (e.g.,  a system  with  support  for  Secret  and  Top 
Secret  users):  open — this  operation  would  support  both  cleared  users 
and  uncleared  users  (or  users  at  unsecured  terminals). 

The  costly  procedures  currently  used  are  made  necessary  by  the 
inability  of  the  current  hardware /software  systems  to  protect  the 
information  they  process.  In  a current  ADP  system,  it  must  be  assumed 
that  any  program  that  runs  on  the  system  can  access  any  information 
physically  accessible  to  the  processor,  and  can  retrieve,  alter,  or 
destroy  the  information  as  the  programmer  wishes.  A number  of 
projects  have  been  undertaken  to  write  programs  that  obtain  access  to 
information  without  authorization;  in  each  case,  total  success  was 
achieved. 

Attempts  to  modify  existing  operating  systems  to  remove  security 
flaws  have  not  been  successful.  Such  ad  hoc  repairs.  In  many  cases, 
nay  render  the  computer  system  inoperative  unless*  a long  and  costly 
series  of  program  modifications  is  made.  In  addition,  complex  program 
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chaages,  lateaded  to  correct  security  flaws,  may  Introduce  new  flaws 
into  other  program  areas. 

The  concept  of  program  completeness  Is  fundamental  In  the  field 
of  multilevel  computer  security.  Even  if  every  known  security  flaw  in 
an  operating  system  is  corrected,  the  final  operating  system  could  not 
be  considered  secure,  since  successful  system  penetrations  only  show 
the  existence  of  flaws,  not  the  lack  of  them.  While  perfect  security 
is  not  required  in  some  areas  (e.g. , physical  and  personnel),  the 
problem  in  computer  security  is  not  analogous  to  those  in  other  areas. 
While  flaws  in  physical  security,  for  example,  may  permit  unauthorized 
access  a small  percentage  of  the  time,  an  operating  system  security 
flaw,  which  allows  compromise  of  Information,  can  be  exploited  at 
will,  providing  undetected  access  to  any  information  in  the  computer. 
Given  tbit  a program  can  and  would  be  written  to  capitalize  on  such  a 
flaw,  c 'lnplete  and  unauthorized  access  could  occur  indefinitely. 

Strict  t ecurlt^  controls  during  design  ;ri(l  production  may  prevent 
uallcious  code  from  being  purposely  Im  rteii;  however,  unless  security 
is  a design  consideration,  the  resulting  systv^-m  may  contain  design 
flaws  that  could  provide  access  to  unauthorized  users. 

This  discussion  shows  that  the  method  of  correcting  security 
flaws  as  they  are  found  in  a system  cannot  produce  a secure  system. 

The  alternative  is  to  develop  a technical  approach  that  results  in  a 
system  to  support  classified  processing  in  a true  multilevel  secure 
mode. 


TECHNICAL  APPROACH  TO  MULTILEVEL  SECURITY 

In  1970,  the  Air  Force  Data  Services  Center  (AFDSC)  asked  the 
Electronic  Systems  Division  (ESD)  to  support  development  of  open 
multilevel  secure  operations  for  AFDSC's  Honeywell  635  computer 
systems.  ESD  and  MITRE  personnel  shortly  reached  the  conclusion  that 
no  set  of  modifications  to  the  635's  operating  system  would  make  ' 
suitable  for  controlled  multilevel  operation,  much  less  for  open 
multilevel  operation  with  uncleared  users  and  terminals. 

To  determine  the  reasons  for  this  difficulty,  and  to  identity 
ways  of  solving  future  multilevel  security  problems,  the  Air  Staff 
directed  ESD  In  1972  to  convene  a computer  security  technology 
planning  study  panel.  The  panel  was  composed  of  recognized  experts 
from  industry,  universities,  and  government  organizations  and  operated 
under  a contract  from  ESD  to  James  P.  Anderson  and  Company.  It  was 
tasked  with  preparing  a development  plan  for  a coherent  approach  to 
attacking  the  problems  of  multilevel  computer  security.  The  panel  was 
supported  by  a requirements  working  group  of  computer  system  staff 
officers  from  ten  Air  Force  commands. 


11 


t 

t 


! 

[ 


! 


The  panel's  report  (2)  identified  the  problem  of  completeness  and 
recognized  the  futility  of  "patching  holes"  in  existing  operating  1 

systems  as  a means  of  providing  multilevel  security*  It  recommended  a 
technical  approach  that  starts  with  a model  of  a secure  system  and 
refines  It  through  various  levels  of  design  Into  hardware /software 
mechanisms  that  Implement  the  model. 

Reference  Monitor 

The  basic  component  of  the  technical  approach  proposed  by  the 
security  technology  panel  is  the  reference  monitor:  an  abstract 
mechanism  that  controls  access  by  subjects  (active  system  elements)  to 
objects  (repositories  of  Information)  within  the  computer  system. 

Figure  1 diagrams  the  relationships  among  subjects,  objects,  reference 
monitor,  and  reference  monitor  data  base.  An  Implementation  of  the 
reference  monitor  abstraction  permits  or  prevents  access  by  subjects 
to  objects,  making  Its  decisions  on  the  basis  of  Information  contained 
In  the  reference  monitor  data  base.  The  Implementation  automates  the 

access  rules  of  the  military  security  system  and  assures  that  they  are  J 

enforced  within  the  computer.  The  technology  panel  stated  that,  to  be 
the  basis  for  a multilevel  secure  computer  system,  a protection 
mechanism  that  Implements  a reference  monitor  must  meet  three 
requirements: 

o Complete  mediation  - the  protection  mechanism  must  be  Invoked 
on  every  access  by  a subject  to  an  object. 

o Isolation  - the  protection  mechanism  and  its  data  base  must  be 
protected  from  unauthorized  alteration. 

o Verifiability  - the  protection  mechanism  must  be  small  and 
simple  enough  so  that  It  can  be  verified  to  perform  its 
function  correctly. 

These  requirements,  and  the  need  for  efficiency,  demand  that  the 
reference  monitor  Implementation  Include  hardware  as  well  as  software, 
since  software  validation  of  every  access  would  add  Intolerable 
complexity  and  overhead  to  the  reference  monitor.  Hardware  features 
considered  essential  to  Implementation  of  a secure  system  include 
segmented  memories,  processors  with  multiple  execution  states,  and 
positive  control  of  all  1/0  devices. 

The  hardware /software  protection  mechanism  that  ImplenKnts  the 
reference  monitor  abstraction  Is  called  the  security  kernel.  The 
software  that  must  be  designed  to  Implement  the  reference  monitor 
abstraction  on  a particular  computer  is  frequently  referred  to  as  the 
security  kernel  for  that  computer. 
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Abstract  Model  of  a Secure  System 

Recognizing  the  Importance  of  the  model  of  an  Ideal  system  as  a 
starting  point,  ESD  Initiated  development  of  a mathematical  model  of 
computer  security  In  1972.  Initial  contributions  were  made  by  The 
MITRE  Corporation  (3)  and  by  Case  Western  Reserve  University  (4,5). 

The  model  specifies  the  requirements  for  the  operation  of  a security 
kernel.  The  basic  requirements  Identified  by  the  model  are  taken 
directly  from  Defense  Department  policy  on  handling  sensitive 
Information. 

The  completed  model  of  secure  computer  systems  represents  a 
secure  computer  system  as  a finite-state  mechanism  that  makes  explicit 
transitions  from  one  secure  state  to  the  next.  The  system  state  Is 
defined  by  the  current  access  capabilities  of  each  subject  to  each 
object.  The  axioms  of  the  model  formally  define  the  conditions  under 
which  a state  transition  can  occur.  The  axioms  allow  only  transitions 
that  preserve  the  security  of  Information  In  the  system.  Transition 
rules  also  may  be  suggested  as  models  of  kernel  functions. 

A significant  property  of  the  model  Is  that  all  but  a special 
collection  of  proven  and  trusted  subjects  are  restricted  from  having 
write  access  to  an  object  at  a lower  classification  than  any  that  It 
may  read.  The  restriction  prevents  Information  obtained  at  the  higher 
level  from  being  transferred  to  a lower  level  where  It  can  be  accessed 
Illegally.  This  property  eliminates  the  need  to  verify  that  all 
non-trusted  programs  do  not  Intentionally  or  Inadvertently  downgrade 
classified  Information. 

Formal  Specification 

The  mathematical  model  deals  with  abstract  entitles  that  must  be 
realized  In  a concrete  fashion.  The  first  step  In  the  process  of 
realizing  the  model  abstractions  Is  to  Impose  finite  resource 
limitations  on  the  abstract  entitles  of  the  model  and  express  the 
resulting  system  as  a formal  specification.  This  specification 
completely  Identifies  the  state  variables  of  the  representation  and 
all  the  functions  that  a user  might  Invoke  to  observe  or  modify  one  of 
these  state  variables.  In  the  realization  of  any  system  based  on  the 
model,  the  objects  must  be  given  certain  attributes  such  as  type  and 
size.  Object  type  and  size  then  become  state  variables,  and  functions 
must  be  provided  In  the  formal  specification  to  observe  and  manipulate 
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specification  has  decomposed  the  system  Into  a series  of  function 
modules,  the  Implementation  of  each  module  Into  a suitable  high-level 
language  follows  the  specification  directly.  The  programs  must  then 
be  proven  correct  with  respect  to  a series  of  assertions,  derivable 
from  the  formal  specification. 

Machine  Language  Representation 

The  programs  developed  from  the  formal  specification  will 
eventually  be  translated  from  a high-level  language  Into  a binary 
machine  language,  to  run  on  a particular  machine.  It  must  then  be 
shown  that  the  resulting  machine  language  corresponds  directly  with 
the  high-level  language  representation. 

Verification  Techniques 

Verification  of  the  security  software  requires  that  the  following 
five  correspondences  be  shown  to  be  correct: 

o Top  level  specification  to  model; 

o Hlgh-order  language  specification  to  top  level  specification; 

o High-order  language  code  to  hlgh-order  language  specification; 

o Machine  language  to  hlgh-order  language  code;  and 

o Microcode  to  machine  language. 

Top  Level  Specification  to  Model 

All  state  variables  In  the  formal  cation  are  regarded  as 

objects.  The  accesses  to  them  are  shov/'  ‘!.i.^sfy  the  requirements 
expressed  In  the  mndel. 

High  -Order  Language  t>peclf  Icatlon  lo  Top  I evel  Sp«>clf  Icatlon 

Unce  the  top  level  specification  is  completed,  the  correspondence 
between  the  top  level  specification  and  a software  level  specification 
must  be  shown.  A methodology  for  showing  this  correspondence  has  been 
developed  by  the  Stanford  Research  Institute  (6);  In  this  methodology, 
a hierarchical  approach  Is  used  to  design  the  software  In  such  a way 
that  Che  proofs  required  will  be  divided  naturally  into  simple  steps. 

Hlgh-Order  Language  Code  to  Hlgh-Order  Language  Specification 

‘ The  correspondence  of  the  hlgh-order  language  code  to  the 

‘ hlgh-order  language  specification  can  be  shown  through  the  use  of  a 
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methodology  Introduced  by  Floyd  (7).  The  code  level  specification  for 
a function  plus  the  code  relations  provide  the  input  and  output 
assertions  required  by  the  Floyd  technique.  Automatic  program 
verification  tools  will  most  likely  need  to  be  employed  at  this  level 
to  produce  a rigorous  and  credible  proof. 

Machine  Language  to  High-Order  Language  Code 

There  are  two  general  approaches  to  the  problem  of  proving  that  a 
machine  language  translation  corresponds  to  a high-level  language 
representation:  use  of  a certified  compiler,  and  use  of  an 
uncertified  compiler  and  a certified  disassembler. 

The  first  approach  establishes  that  the  compiler  being  used 
generates  semantically  correct  machine  language  code  for  any  source 
program.  Without  the  availability  of  certified  compilers,  one  is 
faced  with  writing  a compiler  for  a restricted  subset  of  the 
implementation  language  and  certifying  that  it  compiles  correctly. 

The  second  approach  is  to  compile  the  program  into  machine 
language  and  then  to  disassemble  the  resulting  machine  language  into 
readable  assembly  language.  The  correspondence  of  the  machine 
language  program  to  the  assembly  language  program  would  be  assured  by 
the  certification  of  the  disassembler.  The  correspondence  of  the 
assembly  language  program  to  the  original  program  would  be  established 
manually.  In  this  case,  the  overall  correspondence  of  the  high-level 
language  to  the  machine  language  is  sho\m  by  the  composition  of  two 
smaller  correspondences. 

Microcode  to  Machine  Language 

When  the  instruction  set  of  the  machine  is  to  be  rolcroprogranned, 
attention  should  also  be  given  to  the  correctness  of  the  microcode. 

Summary 

The  above  techniques  have  been  successfully  used  to  provide 
multilevel  security  in  computer  systems.  In  addition,  system 
procurements  are  underway  that  specify  the  use  of  these  multilevel 
security  techniques  for  providing  computer  security  within  the  system. 
In  the  following  subsections,  examples  of  systems  that  have  used  or 
are  planning  to  use  these  techniques  are  presented. 
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EXPERIENCES  IN  SECURE  COMPUTER  SYSTEMS 


I The  following  paragraphs  present  an  overview  of  major  secure 

computer  system  developments  that  apply  hardware /software  controls  for 
the  enforcement  of  security  policy.  The  purpose  of  these  examples  Is 
to  demonstrate  that  security  policy  enforcement  can  be  achieved 
through  multilevel  secure  ADP  systems,  and  to  exhibit  developing 
systems  that  employ  this  technology. 

ESP /MITRE  PDP-11/45  Security  Kernel 

To  demonstrate  the  viability  of  the  security  kernel  technology, 

ESP  directed  MITRE  In  January  1973  to  begin  Implementing  a prototype 
security  kernel  for  the  Digital  Equipment  Corporation  PDP-11/45,  a 
relatively  large,  moderately  priced  minicomputer.  This  kernel  was 
Initially  Intended  to  serve  as  the  base  for  a front-end  communications 
processor  for  use  with  a secure  general-purpose  computer  system  to  be 
developed  later;  however.  It  was  soon  realized  that  the  kernel  could 
also  support  stand-alone  secure  computer  applications  requiring  only  a 
minicomputer,  and  It  could  serve  to  prove  out  the  concept  of  a model 
and  Its  Implementation  In  a security  kernel  long  before  developing  a 
kernel  for  a large  general-purpose  system.  The  ESD/MITRE  PDP-11/45 
kernel  design  provides  a sound  security  foundation  on  which  to  base 
operating  systems  and  applications  programs  that  will  function  In  a 
secure  environment  (8). 

The  ESD/MITRE  kernel  design  for  the  PDP-11/45  was  developed  by 
applying  levels  of  abstraction  to  separate  those  parts  of  the  kernel 
that  Implement  the  security  rules,  objects,  and  subjects  required  by 
the  model.  The  kernel  Implements  separate  sequential  processes  that 
can  cooperate  and  communicate  In  accordance  with  the  rules  of  the 
model.  This  kernel  design  creates  a very  basic  secure  environment 
upon  which  operating  systems  and  application  programs  can  be 

Implemented.  The  access  of  users  (subjects)  to  Information  (objects)  . 

In  such  a kernel-based  system  conforms  to  the  specified  security  rules  I 

since  all  system  and  applications  software  Is  running  on  top  of  the 
security  kernel.  i 

As  a practical  demonstration  of  security  kernel  technology,  a 
MITRE  project  built  a secure,  multilevel  file  management  system  on  the 
PDP-11/45  kernel.  Two  scenarios  using  this  file  system  have  been 
developed  (9).  The  first  of  these  scenarios  uses  a text  editing 
capability  to  show  how  a multilevel  data  base  can  provide  for  data 
storage,  manipulation,  and  retrieval  In  a multilevel  user  environment, 
while  protecting  all  classified  information  from  unauthorized  access. 

The  second  demonstration  employs  an  air  surveillance  data  correlation 
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scenario  that  permits  precisely  controlled,  selective  downgrading  of 
classified  track  data  based  on  the  Informed  Judgment  of  a downgrading 
officer.  The  system  being  demonstrated  allows  users  to  access  the 
widest  possible  range  of  Information  on  the  system  (restricted  only  by 
their  maximum  clearances),  yet  prevents  the  unauthorized  user  from 
accessing  any  classified  Information  not  specifically  downgraded. 

The  PDP-11/45  kernel  design  Is  Implemented  In  a small  structured 
computer  program  and  follows  the  mathematical  model  directly.  This 
PDP-11/45  security  kernel  provides  a demonstration  of  the  feasibility 
of  building  a security  kernel  that  Implements  a security  policy  model. 

AFDSC  Secure  Multlcs 


While  the  security  kernel  for  the  PDP-11/45  constitutes  a small 
secure  system.  Air  Force  commands  need  large  multilevel  secure 
computers.  The  reference  monitor  concept  must  be  demonstrated  to  be 
feasible  In  an  efficient,  as  well  as  secure,  large  resource-sharing 
system.  This  demonstration  Is  necessary  to  show  that  systems  based  on 
the  reference  monitor  concept  can  provide  a viable  solution  to  meeting 
all  Air  Force  ADP  requirements  (not  Just  those  for  security). 

Initial  steps  toward  developing  a secure  system  based  on  Multlcs 
were  taken  In  conjunction  with  development  of  a Multlcs  operating 
system  for  use  In  a two-level  (Secret  and  Top  Secret)  environment  at 
the  Air  Force  Data  Services  Center.  This  system's  design  Is  aimed  at 
providing  security  controls  based  on  the  military  access  rules,  but  it 
does  not  attempt  to  eliminate  completely  the  prospect  of  hostile 
penetration.  The  risk  of  penetration  Is  to  be  reduced  primarily  by 
procedures  and  by  personnel  and  environmental  controls,  rather  than  by 
the  Multlcs  hardware  and  software.  The  Implementation  of  the  access 
rules  In  the  Data  Services  Center  Multlcs  was  based  on  the  concept  of 
a secure  system  model,  but  no  attempt  was  made  to  define  a security 
kernel  for  the  system. 

Honeywell  Information  Systems  began  the  design  of  the  Data 
Services  Center  Multlcs  In  late  1973,  and  It  was  completed  In  mld-1974 
(10).  Implementation  was  completed  In  1975  and  the  system  Is 
currently  In  operation.  As  noted,  the  system  was  designed  for  use  In 
a controlled  environment  where  all  users  are  cleared  to  either  the 
Secret  or  Top  Secret  level.  Because  of  this  benign  environment,  a 
kernel-based  design  was  not  required  for  certification.  This  system 
was  the  first  operational  system  to  be  certified  for  multilevel 
computation  In  DoD.  The  system  was  approved  for  simultaneous 
servicing  of  both  Secret  and  Top  Secret  cleared  personnel  by  the 
Commander,  Air  Force  Data  Automation  Agency,  on  2 December  1976. 
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SATIH  IV 


SATIN  IV,  the  Strategic  Air  Command  (SAC)  Automated  Total 
Information  Network,  Is  a packet-switched  network  that  will  support 
the  World  Wide  Record/Data  Command  Control  Communications  requirements 
of  SAC  and  the  National  Command  Authorities.  Due  to  the  sensitive 
nature  of  the  SATIN  IV  message  traffic,  security  has  been  Identified 
as  a major  design  requirement.  An  Internal  Access  Control  Mechanism 
(lACll)  will  be  used  In  the  SATIN  IV  communications  processors  to 
provide  security  to  messages  at  each  of  the  SAC  base  locations.  This 
lACM,  augmented  by  a number  of  trusted  processes,  draws  heavily  on 
previous  computer  security  technology  work. 

AUTODIN-Il 

AUTODIN-II  Is  a packet-switched  network  to  be  developed  for  the 
Defense  Communications  Agency  (DCA).  Its  aim  Is  to  provide  a common 
Department  of  Defense  communications  system  for  computer-to-computer 
and  termlnal-to-computer  connections.  The  Initial  Operating 
Capability,  which  Includes  three  packet  switching  nodes  (PSNs)  and  a 
Network  Control  Center,  Is  scheduled  for  early  1979. 

As  with  SATIN  IV,  a security  kernel  (referred  to  as  a System 
Security  Module)  will  be  developed  for  use  In  the  PSNs  to  Implement 
the  requirements  of  DoD  security  policy.  The  System  Security  Model  Is 
Intended  to  provide  the  necessary  security  for  messages  as  they  travel 
throughout  the  AUTODIN-II  network. 

Secure  UNIX  Procurement 

Prototype  Secure  UNIX  efforts  have  been  undertaken  at  MITRE  and 
UCLA.  Under  USAF/ESD  sponsorship,  MITRE  Is  Implementing  a prototype 
Secure  UNIX  kernel  on  a PDP-11 /A5.  The  kernel  is  a new  version  of  the 
original  11/45  kernel  developed  at  MITRE,  and  It  Is  largely  coded  In 
the  Bell  Laboratories  C language,  as  Is  the  program  that  establishes 
the  UNIX  Interface.  The  Interface  program,  called  the  Secure  UNIX 
Emulator,  uses  the  kernel-supplied  functions  and  provides  other  needed 
functions  to  duplicate,  as  nearly  as  possible,  the  user  program 
Interface  provided  by  commercial  UNIX. 

An  ARPA-sponsored  effort  at  UCLA  Is  producing  a kernel-based  UNIX 
system  of  different  design  from  the  ESD/MITRE  system.  While  the  UCLA 
kernel  creates  processes  having  a per-process  virtual  environment,  as 
does  the  MITRE  kernel,  the  specific  kernel  Implementation  Is 
different.  The  kernel  provides  for  process  creation  and  control,  page 
control  and  swapping,  and  provides  for  I/O  and  Interprocess 
communication  capabilities.  The  UCLA  kernel  offers  another  design 
approach  to  the  construction  of  a Secure  UNIX. 
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An  ARPA-sponsored  procurement  Is  underway  to  develop  a production 
version  of  a secure  operating  system  that  can  be  used  In  a wide 
variety  of  DoD  applications.  The  results  of  this  procurement  will  be 
a secure  system  based  on  the  security  kernel  technology,  and  offering 
the  features  of  the  UNIX  operating  system.  UNIX  Is  a general-purpose 
timesharing  system  that  operates  on  the  Digital  Equipment  Corporation 
PDP-11  series  computer.  The  UNIX  system  was  designed  to  provide  a 
good  environment  for  the  user  to  develop  and  operate  Information 
processing  and  computational  systems.  UNIX  Is  of  Interest  to  DCA  (as 
a WUMCCS  network  front-end),  to  the  Air  Force  Data  Services  Center 
(for  text  processing  and  Intercomputer  Interfacing),  and  to  the 
Intelligence  community  (for  several  stand-alone  and  network 
applications).  These  UNIX  applications  would,  without  exception,  be 
facilitated  If  they  could  be  Implemented  on  a secure  version  of  UNIX 
capable  of  enforcing  the  DoD  securlcy  policy. 

There  are  six  major  objectives  of  the  Secure  UNIX  procurement: 

o The  resulting  system  shall  be  verlflably  secure  with  respect 
to  DoD  policy. 

o The  resulting  system  shall  provide  adequate  performance. 

o The  resulting  system  shall  allow  applications  programs  written 
for  unsecure  UNIX  to  be  run  without  modification,  provided  the 
program  Is  only  required  to  process  a single  level  of 
Information.  -I 

o The  resulting  system  shall  Include  administrative  and  user  { 

Interface  functions  to  facilitate  the  processing  of  DoD 
classified  Information  In  a true  multilevel  environment. 

o The  resulting  system  shall  support  a single-level  Interface  to  ] 

the  ARPANET,  and  shall  allow  for  the  Incorporation  of  evolving 
multilevel  network  security  protocols. 

o The  resulting  system  shall  be  fully  documented  to  allow  for 
wide  use,  maintenance,  and  enhancement  within  the  DoD 

community.  { 

Work  on  the  Secure  UNIX  development  began  In  August  1977  with  TRW 
and  the  Ford  Aerospace  and  Communications  Corporation  as  contractors. 

Implementation  of  Secure  UNIX  should  be  completed  by  September  1979. 
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SinOlARY  OF  REQUIREMEUIS 


Based  oa  the  discussion  In  this  section,  a number  of  requirements 
must  be  met  to  provide  a true  multilevel  secure  computer  system;  It  Is 
Imperative  that  the  appropriate  DoD  directives  adequately  address  the 
need  for  these  features,  the  features  are  summarized  below. 

A complete  and  provably  secure  representation  of  the  protection 
mechanism  based  on  the  abstract  security  model  Is  needed  to  evaluate 
the  adequacy  of  the  protection  mechanism.  This  formal  reprdftentation 
embodies  the  constraints  Imposed  on  Information  access  by  the  security 
policy.  A protection  mechanism  that  Is  built  based  on  such  a 
representation  can  be  checked  for  adequacy  through  the  following  three 
steps: 

o Validation  - technical  proof  that  security  policy  Is  enforced. 

o Certification  - application  of  technical  and  procedural 

measures  to  a system  to  a degree  commensurate  with  the  threats 
perceived  In  the  system  environment. 

o Accreditation  - official  approval  of  a system  Issued  by  the 
appropriate  authority. 

Such  a protection  mechanism  must  enforce  the  two  properties 
dictated  by  the  security  policy.  These  properties  are: 

o General  Access  Property  - A subject  will  be  allowed  to  read  an 
object  only  If  the  classification  level  of  the  subject  Is 
greater  than  or  equal  to  the  classification  level  of  the 
object,  and  the  subject  Is  authorized  access  to  the  set  of 
categories  that  are  assigned  to  the  Information. 

o Special  Access  Property  - A non-trusted  subject  will  not  have 
read  access  to  an  object  of  a higher  classification  or 
possessing  a more  restrictive  set  of  categories  than  an  object 
to  which  the  subject  concurrently  has  write  access,  l.e.. 
Information  from  an  object  with  a given  classification  and  set 
of  categories  may  only  be  transferred  Into  an  object  with  an 
equal  or  higher  classification  and  category. 

After  a protection  mechanism  Is  developed  that  satisfies  the  two 
properties  described  above.  It  Is  still  necessary  to  assess  the 
overall  security  of  the  ADP  system  based  on  the  Incorporation  of  the 
mechanism  Into  the  system.  Such  an  assessment  can  be  accomplished  In 
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a security  test  and  evaluation  (ST&E)  procedure,  performed  by 
technical  and  security  personnel,  whereby: 

o the  vulnerability  threats  are  Identified; 

o effective  countermeasures  are  determined; 

o the  countermeasures  are  Implemented  In  compliance  with  the 
appropriate  security  directives  and  procedures  for  the 
different  classifications  handled;  and, 

o despite  any  unresolved  security  risks,  the  system  still 
provides  an  adequate  degree  of  security. 

While  this  ST&E  procedure  does  not  In  Itself  guarantee  that  an 
AUP  system  Is  secure.  It  Is  a step  required  to  determine  the  overall 
system's  ability  to  provide  the  security  dictated  In  DoD  policy. 

In  addition  to  the  above  development  of  a protection  mechanism 
and  the  evaluation  of  the  security  of  an  ADP  system,  strict  controls 
are  needed  during  design  and  production  of  the  system,  since  a 
protection  mechanism  will  be  of  little  value  If  unauthorized  code 
(e.g.,  a trap  door  or  trojan  horse  program)  Is  Inserted  during  system 
construction. 


Thus,  the  directives  must  dictate  that  at  least  the  following 
criteria  be  satisfied  to  Insure  that  security  policy  requirements  are 
met  and  that  security  policy  Is  enforced: 

o The  general  access  and  special  access  properties  must  be 
adhered  to  for  every  read  or  write  operation  within  the 
system. 

o No  system  software  shall  be  put  In  operation  until  It  has  been 
suitably  verified,  certified,  and  accredited  for  general  use 
by  the  proper  approving  authorities. 

o Security  test  and  evaluation  procedures  must  be  used  to 

determine  the  overall  system's  ability  to  enforce  DoD  security 
policy. 

o Controls  must  be  Implemented  during  all  stages  of  design  and  I 

production  to  Insure  that  no  disruptive  code  Is  inserted  Into  i 

the  system  procedures. 

The  next  section  examines  the  directives  In  light  of  these  necessary 
criteria. 
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SECTION  III 


ADDITIONS  AND  MODIFICATIONS  TO  EXISTINC  DIRECTIVES 


The  previous  section  discussed  security  policy  In  ADP  systems, 
and  how  the  problem  of  providing  a true  multilevel  secure  environment 
Is  being  addressed.  As  shown,  systems  exist  and  are  being  developed 
to  handle  all  classification  levels  of  Information  simultaneously 
within  a computer  system.  Based  on  those  developments,  this  section 
examines  three  existing  directives  (DoD  5200.28,  DoD  5200. 28M,  and  AFR 
300-8)  to  determine  what  additions  and  modifications  are  necessary  to 
reflect  this  availability  of  multilevel  secure  coiq>uter  technology. 

In  particular,  the  areas  summarized  at  the  end  of  the  previous  section 
will  be  considered  for  this  set  of  directives.  A general  discussion 
of  the  additions  and  modifications  Is  followed  by  specific  discussion 
for  each  directive. 


GENERAL 

One  main  area  where  the  directives  lack  completeness  Is  In 
specifying  the  application  of  design  and  production  controls. 

Adequate  controls  are  necessary  during  the  design  and  production 
cycles  of  an  ADP  system  to  Insure  that  devices  and  programs  that  might 
be  used  to  compromise  classified  Information  during  system  operation 
cannot  be  Inserted  without  detection.  The  directives  must  explicitly 
state  the  need  for  adequate  controls  during  design  and  production. 

The  directives  must  also  state  more  clearly  the  need  for 
certified  dependability  In  Implementing  the  security  controls;  In 
addition,  the  responsibility  and  authority  for  accrediting  a system 
must  be  Identified. 


DOD  DIRECTIVE  5200.28 

DoD  Directive  5200.28,  "Security  Requirements  for  Automatic  Data 
Processing  (ADP)  Systems",  presents  the  security  requirements  that 
must  be  adhered  to  when  Implementing  an  ADP  system.  As  currently 
written,  this  directive  Is  not  sufficiently  definitive  on  the  extent 
of  dependability  that  the  ADP  security  procedures  must  maintain.  When 
considering  the  simultaneous  processing  of  information  of  different 
classification  levels.  It  Is  clear  that  a system  must  be  certain  to 
Incorporate  proper  safeguards  to  prevent  undetected  security 
violations.  The  state-of-the-art  In  computer  security  Is  such  that 
these  safeguards  can  be  achieved.  Consequently,  the  directive  should 
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require  chat  any  ADP  security  procedures  are  shown  to  be  certified  for 
protecting  all  classified  Information.  This  certification  requirement 
Is  needed  as  an  assurance  Chat  the  system  upholds  the  security  policy. 

Since  present  ADP  security  technology  has  developed  mainly  In  Che 
time  after  this  directive  was  Issued,  the  directive  does  not  address 
security  properties  Chat  have  been  Identified  as  peculiar  Co  Che  ADP 
environment.  Although  the  general  access  property  Is  covered  to  the 
extent  that  protection  against  compromise  Is  required,  Che  special 
access  property  Is  not  addressed.  This  property,  and  the  requirement 
Chat  security  protection  mechanisms  support  It,  must  be  Incorporated 
Into  Che  directive.  In  addition,  suitable  mechanisms  must  be  provided 
In  a system  to  handle  Che  enforcement  of  discretionary  and 
non-dlscretlonary  controls. 

This  directive  restricts  contractor  processing  of  classified 
Information  to  systems  that  are  operated  In  the  dedicated  mode; 
however,  with  the  development  of  secure  multilevel  systems,  this 
restriction  could  be  eased  to  allow  contractor  processing  of 
classified  material  on  either  a dedicated  system  or  a system  that  has 
been  certified  as  multilevel  secure. 

Any  ADP  system  that  will  be  processing  classified  Information 
must  meet  Che  security  requirements  set  forth  In  this  directive. 

While  verification  and  certification  procedures  can  show  chat  Che 
system  Is  secure,  some  authority  must  accredit  these  findings  and 
declare  the  system  suitable  for  operational  use.  This  accrediting 
authority  has  not  been  Identified  within  the  directive  and  must  be 
Included. 

The  minimum  requirements  for  effective  security,  as  set  forth  In 
the  directive,  must  be  expanded  Co  cover  design  and  production 
controls.  As  the  previous  section  showed,  security  during  these 
stages  of  system  development  Is  critical  to  the  ultimate  system 
operational  security. 


DOD  MANUAL  5200. 28M 

DoD  Manual  5200. 28M,  "Manual  of  Techniques  and  Procedures  for 
Implementing,  Deactivating,  Testing,  and  Evaluating  Secure 
Resource-Sharing  ADP  Systems",  discusses  methods  available  Co 
Implement  an  ADP  system  chat  satisfies  the  requirements  set  forth  In 
DoD  5200.28.  As  In  DoD  5200.28,  this  manual  should  be  modified  to  be 
more  definite  regarding  the  extent  of  dependability  Chat  must  be 
maintained  by  ADP  security  procedures.  The  manual  should  require 
certified  dependability  for  ADP  systems  handling  classified  material, 
rather  Chan  simply  "reasonable  dependability". 


24 


A 


Vrhile  clearaace  and  access  controls  are  discussed  within  the 
manual*  these  controls  must  be  made  more  specific  for  the  design  and 
production  phases  of  system  development.  As  currently  written*  these 
controls  apply  only  to  operating  system  programming  personnel*  and 
seem  to  be  applicable  mainly  to  programming  occurring  after  system 
Installation.  A separate  paragraph  In  Section  II  of  the  manual  should 
clearly  detail  the  clearance  and  access  control  requirements  during 
design  and  production. 

This  manual  discusses  the  application  of  a coiid>lnatlon  of 
hardware  and  software  features  to  provide  protection  to  classified 
Information  In  ADP  systems.  In  this  regard*  the  concept  of  a 
reference  monitor  and  the  security  kernel  as  an  implementation  of  the 
reference  monitor*  for  mediating  all  accesses  of  subjects  to  objects* 
should  be  Included.  This  additional  Information  could  be  added  to  the 
discussion  of  hardware /software  features  In  Section  IV. 

The  description  of  the  hardware  features  In  Section  IV  of  the 
manual  can  be  expanded  In  light  of  the  minimum  hardware  requirements 
that  have  been  Identified  as  necessary  to  support  secure  ADP  software. 

As  presently  worded*  this  section  deals  mainly  with  control  of 
processor  actions*  e.g.*  error  detection  on  memory  fetches  and  known 
responses  by  all  operation  codes.  In  addition  to  hardware  features 
such  as  these*  other  features  to  provide  Isolation  of  the  security 
kernel  and  the  ability  to  manipulate  subject  and  object  access 
attributes  must  exist  In  a secure  system.  Although  Implied  In  the 
hardware  discussion,  the  necessity  for  multiple  execution  domains  and 
segmented  memory*  or  equivalent  capabilities*  In  the  processor  must  be 
explicitly  noted. 

This  manual  states  that  the  operating  system  shall  contain 
controls  that  provide  the  user  with  all  material  to  which  he  Is 
authorized  and  no  more.  As  noted*  such  controls  could  be  Implemented 
through  the  use  of  a security  kernel  Implementation  of  a reference 
monitor  that  mediates  all  access  of  subjects  (users  or  user  processes) 
to  objects  (data  material).  Since  the  security  kernel  provides  the 
security  needed  In  the  operating  system*  this  technique  satisfies  the 
requirements  of  the  manual.  As  presently  written*  the  manual  does  not 
make  It  clear  that  the  use  of  security  kernel  technology  is  a feasible 
and  acceptable  solution  to  Implementing  security  controls. 

I 

* The  Security  Testing  and  Evaluations  section  can  be  expanded  to  i 

Include  not  only  the  need  for  validating*  certifying*  and  accrediting 
the  security  measures  used  for  a given  ADP  system*  but  how  these 

* evaluations  can  be  accomplished. 

i 
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Auditing  and  surveillance  can  provide  feedback  on  how  users  are 
enploying  the  ADP  system.  Such  techniques  augment  the  security 
controls  of  the  ADP  system.  VThlle  existing  manuals  require  that 
records  be  kept  of  logins,  file  creations,  file  accesses,  and 
classified  outputs,  it  is  equally  Important  that  attempts  to 
circumvent  the  security  rules  be  recorded  as  well.  In  addition, 
changes  to  system  status  should  be  recorded  so  that  an  accurate 
history  of  system  operation  can  be  maintained.  Additional  items  to  be 
recorded  would  Include:  failures  of  logins,  file  accesses,  file 
creations,  or  classified  output  attempts;  changes  to  access 
privileges:  changes  to  directories;  downgrading  attempts;  hardware 
failures;  and,  system  crashes.  The  system  security  officer  should  be 
provided  with  the  capability  to  monitor  security-related  events  while 
in  progress,  as  a means  of  detecting  violations  as  they  occur.  The 
extent  to  which  these  auditing  and  surveillance  features  would  be 
Incorporated  into  an  ADP  system  would  depend  on  the  requirements  of 
the  specific  ADP  system. 
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AIR  FORCE  REGULATION  300-8 

Air  Force  Regulation  300-8,  "Security  Requirements  for  Automatic 
Data  Processing  Systems  (ADPS)",  establishes  policy  and  assigns 
responsibilities  for  the  implementation  of  ADP  security  procedures  in 
Air  Force  systems.  This  regulation  presents  the  Air  Force-specific 
amplifications  to  the  security  requirements  and  procedures  put  forth 
in  DoD  5200.28  and  5200. 28M. 

For  any  system,  a model  must  be  developed,  incorporating  the 
minimum  requirements;  such  a model  can  be  used  for  comparison  to  the 
actual  system  and  determining  the  adherence  to  the  minimum 
requirements.  This  regulation  must  incorporate  the  concept  of 
developing  a model  as  a means  of  checking  a system  and  its  security 
procedures. 

As  in  the  previous  two  cases,  this  regulation  does  not  fully 
explain  the  requirements  for  design  and  production  controls  during 
system  development.  The  regulation  does  state  that  the  application  of 
design  and  production  controls  during  system  development  must  be 
assured;  however,  details  on  these  design  and  production  requirements, 
and  the  responsibility  for  setting  these  requlreownts,  are  lacking. 

An  additional  paragraph  must  be  added  to  the  "Minimum  Requirements" 
section  to  expand  on  the  requirement  for  adequate  security  controls 
during  design  and  production.  In  the  responsibilities  section,  the 
responsibility  to  set  the  requirements  of  design  and  production 
controls  must  be  added  to  the  stated  responsibilities  for  such  areas 
as  security  approval  procedures  and  approval  of  ADP  systems  to  handle 
classified  material. 
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The  "Mlnlnum  Requirements"  outlined  In  this  regulation  should  be 
reflected  In  the  model  used  to  analyze  the  final  system  configuration. 
Consequently,  this  regulation  must  include  the  requirement  that  the 
model  Incorporate  the  minimum  requirements  as  presented. 


SECTION  IV 


( 

ii 

i' 
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CONCLUSIONS  AND  RECOMMENDATIONS 


It  Is  clear  Iron  Che  discussion  In  this  paper  that  existing  DoD 
ADP  system  directives  need  to  be  updated  to  reflect  the  new 
developments  in  computer  security  technology*  As  mentioned  In  the 
Introduction,  Che  directives  recognize  the  need  for  updating  «ihen  new 
developments  In  ADP  system  security  are  available.  With  security 
kernel  technology  now  being  used  and  being  planned  for  use  In  a number 
of  systems,  the  fact  that  new  developments  are  available  becomes 
apparent. 

It  Is  recommended  that  these  three  directives  (DoD  5200.28,  DoD 
5200.2^,  and  APR  300-8)  be  suitably  revised  Co  reflect  the 
state-of-the-art  In  computer  security  technology.  This  paper  has 
Identified  the  major  areas  of  revision,  and  appropriate  changes  have 
been  suggested. 

It  has  been  recognized  that  security  cannot  be  "added-on"  Co  a 
design.  Many  DoD  directives  Influence  the  hardware  and  software 
design  cycle.  While  specific  changes  are  recommended  for  Che  above 
three  directives,  a general  security  awareness  In  all  system  design 
and  operations  directives  also  Is  needed. 
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APPENDIX  1 

PROPOSED  CHANGES  TO  DOD  5200.28 


This  appendix  presents  specific  word  changes  that  would  modify 
DoD  5200.28  to  reflect  the  suggested  additions  and  modifications 
discussed  In  Section  III. 


* 
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SECTION  I - PURPOSE 

Part  B3  currently  states  that  systems  that  handle  classified 
Information  will,  "with  reasonable  dependability",  prevent 
unauthorized  access  or  modification.  The  phrase,  "with  reasonable 
dependability",  should  be  changed  to  reflect  the  addition  of 
certification  requirements  Into  subsequent  sections.  Two  alternate 
phrases  are:  "with  dependability",  or  "with  certified  dependability". 


SECTION  111  • DEFINITIONS 

Any  additional  computer  security  terms  used  In  these  changes  must 
be  added  to  the  definition  list  Included  as  Enclosure  2.  (See 
additions  to  Enclosure  2 - Definitions.) 


SECTION  IV  - POLICY 

Part  A states  that  each  DoD  component  shall  assure  adherence  to 
the  policies.  This  part  could  be  changed  to  Include  a certification 
requirement  (e.g.,  each  DoD  component  shall  certify...);  the 
certifying  authority  Is  described  In  a later  part. 

A new  part  should  be  added  to  this  section  to  detail  the 
requirement  to  satisfy  the  general  access  and  special  access 
properties,  and.  In  addition,  the  requirement  to  provide  discretionary 
and  non-dlscretlonary  controls.  This  new  part  would  read  as  follows: 
"The  security  measures  for  ADP  systems  operating  In  a true  multilevel 
secure  mode  shall  be  Implemented  to  enforce  both  the  general  access 
and  special  access  properties,  and  to  provide  discretionary  and 
non-dlscretlonary  controls." 

In  Part  0,  the  handling  of  Top  Secret  Information  by  a contractor 
ADP  system  Is  restricted  to  system  operating  In  a dedicated  mode. 

This  restriction  could  be  modified  to  Include  the  alternative  of 
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Introducing  Top  Secret  information  to  a contractor  ADP  system  that  has 
been  "certified  as  multilevel  secure  by  a cognizant  DoD  authority." 


SECTION  V - RESPONSIBILITIES 

To  the  responsibilities  of  the  DoD  component  Designated  Approving 
Authority  (Part  C),  the  accreditation  authority  must  be  added.  This 
authority  will  decide  if  the  system  is  acceptable,  based  on  the 
findings  of  the  certification  authority. 


SECTION  VI  - MINIMUM  REQUIREMENTS 

A new  part  should  be  Included  on  "Design  and  Production 
Controls".  This  part  would  deal  with  software  development  in  a 
classified  environment.  The  new  part  would  be  as  follows:  "8. 
Desien  and  Production  Controls.  Adequate  security  controls  shall  be 
provided  to  assure  that  the  system  security  controls  are  protected 
from  subversion  during  system  design  and  production." 


ENCLOSURE  2 - DEFINITIONS 

The  following  definitions  should  be  added  to  Enclosure  2: 

Discretionary  Controls  - a protection  policy  that  may  be 
dynamically  defined  by  the  user. 

Non-Dlscretlonarv  Controls  - a protection  policy  that,  once 
defined  for  an  object,  is  unchangeable  and  must  be  satisfied  for 
all  states  of  the  system. 

General  Access  Property  - A subject  will  be  allowed  to  read  an 
object  only  if  the  classification  level  of  the  subject  is  greater 
than  or  equal  to  the  classification  level  of  the  object,  and  the 
subject  is  authorized  access  to  the  set  of  categories  that  are 
assigned  to  the  information. 

Special  Access  Property  - A non-trusted  subject  will  not  have 
read  access  to  an  object  of  a higher  classification  or  possessing 
a more  restrictive  set  of  categories  than  an  object  to  which  the 
subject  concurrently  has  write  access. 
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APPENDIX  II 


PROPOSED  CHANGES  TO  DOD  5200. 28M 


This  appendix  presents  specific  word  changes  that  would  modify 
DoD  5200. 23M  to  reflect  the  suggested  additions  and  modifications 
discussed  In  Section  II. 


SECTION  I - GENERAL  PROVISIONS 
Part  1 - Introduction 

The  objective  should  be  modified  along  the  lines  of  the  DoD 
5200.28  changes,  such  as  Including  the  term  "certified  dependability". 
The  responsibilities  outlined  In  this  part  must  Include  the 
certification  and  accreditation  authority  designations. 


SECTION  II  - PERSONNEL  SECURITY 
Part  1 - Clearance  and  Access  Controls 

Although  this  part  mentions  the  need  for  the  proper  clearance  of 
ADP  personnel,  additional  Information  must  be  Included  on  the 
clearance  and  access  controls  during  design  and  production.  This 
additional  Information  could  be  Included  as  a new  paragraph  within 
this  part,  or  the  design  controls  mentioned  In  paragraph  2-1U2, 
Operation  and  Operating  System  (0/S)  Programming  Personnel,  could  be 
made  more  explicit. 

SECTION  IV  - HARDWARE /SOFTWARE  FEATURES 
Part  1 - General 

This  part  discusses  the  use  of  a combination  of  hardware  and 
software  to  provide  the  ADP  security  protection.  This  part  can  be 
expanded  to  Include  additional  background  Information  dealing  with  the 
reference  monitor  and  security  kernel  concepts.  The  major  point  to  be 
included  Is  that  "the  concept  of  a reference  monitor  and  the  security 
kernel  as  an  Implementation  of  Che  reference  monitor,  for  mediating 
all  accesses  of  subjects  (processes)  to  objects  (data  or  files).  Is  an 
example  of  a technique  to  provide  protection  for  material  stored  or 
processed  In  secure  ADP  systems." 
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Part  2 - Hardware 


The  follovlng  paragraph  would  Identify  additional  hardware 
features  necessary  in  secure  ADP  systeos: 

"Additional  hardware  features  oust  be  included  to  provide 
isolation  of  the  protect!  raechanisn  and  to  provide  the  ability  to 
manipulate  subject  and  o^^.ct  access  attributes." 

Part  3 - Software 


The  reference  monitor  and  security  kernel  concepts  should  be 
incorporated  into  Paragraph  4-301  - 0/S  Controls.  The  following 
sentence  could  be  added:  "Such  controls  could  be  Implemented  through 
the  use  of  a security  kernel  implementation  of  a reference  monitor 
that  mediates  all  accesses  of  subjects  to  objects." 


SECTION  IX  - SECURITY  TESTING  AND  EVALUATIONS  (ST&E) 

The  goals  of  the  ST&E  procedures  could  be  added  to  this  section 
using  the  following  paragraph: 

"To  assess  the  overall  security  of  the  ADP  system  with  a 
procedure  whereby: 

- the  vulnerability  threats  are  identified; 

- effective  countermeasures  are  determined; 

- the  countermeasures  are  implemented  in  compliance  with  the 
appropriate  security  directives  and  procedures  for  the 
different  classifications  handled;  and 

- despite  any  unresolved  security  risks,  the  system  still 
provides  an  adequate  degree  of  security." 


APPEIIDIX  III 


PROPOSED  CHANGES  TO  APR  300-8 


This  appendix  presents  specific  word  changes  that  would  modify 
AFR  300-8  to  reflect  the  suggested  additions  and  modifications 
discussed  In  Section  111. 


PART  3 - PARAGRAPH  C 

The  need  for  a complete  and  provably  secure  representation  of  the 
protection  mechanism  should  be  Incorporated  Into  this  part.  Following 
the  discussion  of  the  need  for  comprehensive  testing,  this  sentence 
should  be  added:  "A  complete  and  provably  secure  representation  of 
the  prot<jctlon  mechanism  used  In  the  system  must  be  developed  for  use 
In  detcriilnlng  the  adherence  of  the  system  to  the  minimum  requirements 
of  this  regulation." 

PART  4 - INTRODUCTION 

In  the  Introduction  to  this  part,  words  should  be  added  that 
explain  the  need  for  the  system's  protection  mechanism  to  reflect  the 
minimum  requirements  as  set  forth  In  this  part.  After  the  discussion 
of  the  Initial  testing  and  evaluation,  the  following  should  be  added: 
"The  protection  mechanism  that  Is  developed  for  the  ADP  system  must 
satisfy  the  minimum  requirements  for  Internal  system  security  as  set 
forth  below." 


PART  4 - PARAGRAPH  H 

A new  paragraph  should  be  added  under  "Minimum  P.equlruments"  to 
reflect  the  requirement  for  adequate  controls  during  the  design  and 
production  phases  of  system  development.  This  paragraph  expands  upon 
the  objective  set  forth  in  part  2.b(l)  of  the  regulation.  The 
paragraph  would  be  as  follows: 

"h.  Design  and  Production  Controls.  Adequate  controls  are 
Instituted  to  assure  that  the  necessary  system  security 
controls  are  protected  from  subversion  during  system  design 
and  production." 


PART  6 - PARAGRAPH  A 


A paragraph  nust  be  added  to  this  part  to  Identify  the 
responsibility  for  setting  the  requlrenents  of  design  and  production 
controls.  Since  this  responsibility  is  of  a critical  nature.  It  would 
most  likely  fall  under  the  Office  of  Primary  Responsibility.  The 
additional  paragraph  would  be  as  follows: 

"(7)  Establishes  the  requirements  for  design  and  production 
controls  necessary  to  assure  the  protection  of  security 
controls  during  these  phases  of  system  development.” 
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